home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / UNSPLIT / text0562.txt < prev    next >
Encoding:
Text File  |  1997-02-06  |  3.2 KB  |  76 lines
  1.  
  2. > The sound as I understand this must be the ingame-sound-fx. And yes, that I 
  3. > could code. I have thougth about it today (While working hard!!!) and come 
  4. > up with this solution:
  5.  
  6. This all makes sense, but you might want to think about priority decay, so
  7. that samples which have previously been started reduce in priority as time
  8. advances - ensuring that all or most samples are triggered, even if they
  9. are never completed. Very important for spot effects which have a decaying
  10. envelope.
  11.  
  12. > Maximum of 4 or 8 mixed sounds. (Selecteble while playingprefably) Each of 
  13.  
  14. Great - just like Doom.
  15.  
  16. > And now to the actual replay:
  17.  
  18. Again, no problem with 12.25khz - but remember that we need adjustable
  19. frequency playback so we can 'turbulate' monster noises. This way we can
  20. avoid deja-vu with repeated grunts & gunfire at the same pitch.
  21.  
  22. Doom gets round this horrible effect by playing each sample at a random
  23. frequency based around a fixed pitch of (around) 9khz.
  24.  
  25. We could go further by having a slightly random 'shift' in pitch over time -
  26. just enough to remove the repetitive quality. This should require no additional
  27. CPU overheads beyond standard variable pitch.
  28.  
  29. I realise we will have to suffer lower quality audio (6 or 12k) to achieve this
  30. and still retain plenty of CPU time, but the game will sound terrible without this
  31. random pitch turbulation when there are more than 2 monsters nearby.
  32.  
  33. > The second time loss/winning is having inerleaved replayed...  Lets show 
  34. > what I mean. A comma separates the sample bytes (stereo not shown).
  35. > A+B,C+D,A+B,C+D,A+...   (Interleaved)
  36. > A+B+C+D,A+B+C+D,A+...   (Non interleaved)
  37. > I do not know if interleaved will sound terible for 12.kHz or not... But if 
  38. > not then the time winning would be good.
  39.  
  40. You could try it and see - and even keep it as an option for slow machines if
  41. it turns out a bit rough, but I think we will still need a fully mixed version
  42. of the driver - especially considering how many accelerators are kicking around
  43. now.
  44.  
  45. > The replay code will land on nearly 200k of RAM, if I can cood it as I want 
  46. > to... This includes some tables for 3D sound and such, but I think I could 
  47. > get it very fast with some effort put into it. And that I will do!
  48.  
  49. 200k of code - are you considering code generation? Remember this will not
  50. cache on the 68030 and 68040 - and tables can suffer in a similar fashion due
  51. to heavy thrashing (random access).
  52.  
  53. I would prefer to avoid heavy generated code unless it really does offer
  54. fantastic benefits over cached loops. If the 200k is for volume tables and
  55. other conversion data then I can't really see the problem anyway.
  56.  
  57. > Before I begin, I want to know how you want the interface for adding new 
  58. > sounds to be played, and inprovements, tips, and most important if someone 
  59. > already have started on theese routines...
  60.  
  61. Nobody I am aware of has looked very far into the audio side. As for an interface,
  62. something like this:
  63.  
  64. * sample index (1-100 etc.)
  65. * envelope index (table modifies local volume over time in 50hz slices)
  66. * base volume (0-255 etc.)
  67. * base pitch
  68. * turbulence factor (converted to random pitch offset & perhaps a gradient)
  69. * base priority (0-3 - 0=ambient_fx 1=normal_spot_fx 2=override_all)
  70. * x,y map coordinates
  71.  
  72. Or something like that. These are the ones that spring to mind anyway...
  73.  
  74. Doug.
  75.  
  76.